Stack trace API · V8

All internal errors thrown in V8 capture a stack trace when they are created. This stack trace can be accessed from JavaScript through the non-standard error.stack property. V8 also has various hooks for controlling how stack traces are collected and formatted, and for allowing custom errors to also collect stack traces. This document outlines V8’s JavaScript stack trace API.

By default, almost all errors thrown by V8 have a stack property that holds the topmost 10 stack frames, formatted as a string. Here’s an example of a fully formatted stack trace:

The stack trace is collected when the error is created and is the same regardless of where or how many times the error is thrown. We collect 10 frames because it is usually enough to be useful but not so many that it has a noticeable negative performance impact. You can control how many stack frames are collected by setting the variable

Setting it to 0 disables stack trace collection. Any finite integer value can be used as the maximum number of frames to collect. Setting it to Infinity means that all frames get collected. This variable only affects the current context; it has to be set explicitly for each context that needs a different value. (Note that what is known as a “context” in V8 terminology corresponds to a page or in Google Chrome). To set a different default value that affects all contexts use the following V8 command-line flag:

To pass this flag to V8 when running Google Chrome, use:

The --async-stack-traces flag (turned on by default since V8 v7.3) enables the new zero-cost async stack traces, which enriches the stack property of Error instances with async stack frames, i.e. await locations in the code. These async frames are marked with async in the stack string:

At the time of this writing, this functionality is limited to await locations, Promise.all() and Promise.any(), since for those cases the engine can reconstruct the necessary information without any additional overhead (that’s why it’s zero-cost).

The stack trace mechanism used for built-in errors is implemented using a general stack trace collection API that is also available to user scripts. The function

adds a stack property to the given error object that yields the stack trace at the time captureStackTrace was called. Stack traces collected through Error.captureStackTrace are immediately collected, formatted, and attached to the given error object.

The optional constructorOpt parameter allows you to pass in a function value. When collecting the stack trace all frames above the topmost call to this function, including that call, are left out of the stack trace. This can be useful to hide implementation details that won’t be useful to the user. The usual way of defining a custom error that captures a stack trace would be:

Passing in MyError as a second argument means that the constructor call to MyError won’t show up in the stack trace.

Unlike Java where the stack trace of an exception is a structured value that allows inspection of the stack state, the stack property in V8 just holds a flat string containing the formatted stack trace. This is for no other reason than compatibility with other browsers. However, this is not hardcoded but only the default behavior and can be overridden by user scripts.

For efficiency stack traces are not formatted when they are captured but on demand, the first time the stack property is accessed. A stack trace is formatted by calling

and using whatever this call returns as the value of the stack property. If you assign a different function value to Error.prepareStackTrace that function is used to format stack traces. It gets passed the error object that it is preparing a stack trace for, as well as a structured representation of the stack. User stack trace formatters are free to format the stack trace however they want and even return non-string values. It is safe to retain references to the structured stack trace object after a call to prepareStackTrace completes so that it is also a valid return value. Note that the custom prepareStackTrace function is only called once the stack property of Error object is accessed.

The structured stack trace is an array of CallSite objects, each of which represents a stack frame. A CallSite object defines the following methods

The default stack trace is created using the CallSite API so any information that is available there is also available through this API.

To maintain restrictions imposed on strict mode functions, frames that have a strict mode function and all frames below (its caller etc.) are not allow to access their receiver and function objects. For those frames, getFunction() and getThis() returns undefined.

The API described here is specific to V8 and is not supported by any other JavaScript implementations. Most implementations do provide an error.stack property but the format of the stack trace is likely to be different from the format described here. The recommended use of this API is:

The default stack trace format used by V8 can for each stack frame give the following information:

Any of these may be unavailable and different formats for stack frames are used depending on how much of this information is available. If all the above information is available a formatted stack frame looks like this:

Or, in the case of a construct call:

Or, in case of an async call:

If only one of functionName and methodName is available, or if they are both available but the same, the format is:

If neither is available is used as the name.

The Type value is the name of the function stored in the constructor field of this. In V8, all constructor calls set this property to the constructor function so unless this field has been actively changed after the object was created it, it holds the name of the function it was created by. If it is unavailable the [[Class]] property of the object is used.

One special case is the global object where the Type is not shown. In that case the stack frame is formatted as:

The location itself has several possible formats. Most common is the file name, line and column number within the script that defined the current function:

If the current function was created using eval the format is:

…where position is the full position where the call to eval occurred. Note that this means that positions can be nested if there are nested calls to eval, for instance:

If a stack frame is within V8’s libraries the location is:

…and if is unavailable, it’s:

Except as otherwise noted, any code samples from the V8 project are licensed under V8’s BSD-style license. Other content on this page is licensed under the Creative Commons Attribution 3.0 License. For details, see our site policies.